This section is intended to provide a background to the various embodiments of the technology described in this disclosure. The description in this section may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and/or claims of this disclosure and is not admitted to be prior art by the mere inclusion in this section.
Due to the popularization of advanced wireless terminal devices (such as smart phones, tablets and laptops), demands for data-hungry, multimedia services in wireless communication networks have been increasing significantly.
In such a context, the so-called Evolved Multimedia Broadcast Multicast Service (E-MBMS), which is evolved from the MBMS proposed for Universal mobile telecommunication system Terrestrial Radio Access Network (UTRAN), has been introduced in Release 8 of the 3rd Generation Partnership Project (3GPP) Long Term Evolution (LTE) standards for delivering the same multimedia contents simultaneously from multiple eNodeBs within a Multimedia Broadcast multicast service Single Frequency Network (MBSFN) area to multiple user equipments (UEs) within the area.
By way of example, FIG. 1 illustrates an E-MBMS service area, which can be divided into multiple MBSFN areas. In each of the MBSFN areas, there are deployed multiple eNodeBs, all of which can be synchronized to perform MBSFN transmission, that is, to transmit the same multimedia contents simultaneously to multiple UEs within the MBSFN area as mentioned above. In practical implementation, some of the eNodeBs within the MBSFN area may be reserved for other purposes than to perform MBSFN transmission. In FIG. 1, these reserved to eNodeBs are also illustrated.
FIG. 2 schematically illustrates an exemplary E-MBMS network architecture specified by 3GPP. Being compatible with Evolved Packet System (EPS) networks, the illustrated network architecture comprises two additional logical network entities: Multi-cell/Multicast Coordination Entity (MCE) and MBMS Gateway (GW).
The MCE is responsible for allocation of time and frequency resources for multi-cell E-MBMS transmission and ensures that the same resource block is allocated for a given E-MBMS service to all eNodeBs within a given MBSFN area. That is, the task of the MCE is to appropriately configure the Radio Link Control (RLC)/Medium Access Control (MAC) layers at the eNodeBs so as to enable the eNodeBs to perform MBSFN transmission. The MCE may be integrated in at least one of the eNodes as illustrated in FIG. 2. Alternatively, the MCE may be implemented as an individual network entity separate from the eNodeBs.
The MBMS GW is placed between an Evolved Broadcast Multicast Service Centre (E-BMSC) and eNodeBs and is mainly responsible for forwarding E-MBMS packets from the E-BMSC to all eNodeBs performing MBSFN transmission. By means of Internet Protocol (IP) multicast, the MBMS GW directly forwards E-MBMS user data to the eNodeBs. On the other hand, it performs E-MBMS session control signaling (such as SESSION START/STOP) towards the Evolved-UTRAN (E-UTRAN) via a Mobility Management Entity (MME).
Accordingly, between the MBMS GW and each of the eNodeBs, there lies an M1 interface which is a pure user plane interface and thus no control plane application part is defined therefor. Via the M1 interface, point-to-multipoint delivery of user packets from the MBMS GW to the eNodeBs is performed by means of the IP multicast as mentioned above.
Between the MME and the MCE, there lies an M3 interface, for which an application part is defined to allow for E-MBMS session control signaling (including, for example, E-MBMS SESSION START, E-MBMS STOP, etc.) on Enhanced-Radio Access Bear (E-RAB) level (i.e., no radio configuration data for eNodes performing the MBSFN transmission is conveyed). For signaling transport, the Stream Control Transmission Protocol (SCTP) is applied. That means the signaling is transported in point-to-point manner.
In case the MCE is separate from an eNodeB, there lies an M2 interface between the MCE and the eNodeB. For this interface, an application part is defined to convey not only the radio configuration data but also the session control signaling. Also, the SCTP is adopted for point-to-point signaling transport. In case the MCE is integrated in the eNodeB, the M2 interface is replaced by an internal interface inside the eNodeB.
Up to now, no consideration has been given to downlink power control for E-MBMS, which eNodeBs within an MBSFN area collectively provide to multiple UEs within the area by performing MBSFN transmission. Instead, the eNodeBs typically perform the MBSFN transmission using constant transmission powers.
As an example of the application of the typical MBSFN transmission scheme, FIG. 3 depicts a scenario where eNodeBs A, B and C collectively provide E-MBMS to UEs i, j and k by performing MBSFN transmissions using constant transmission powers. As illustrated, UE k receives all transmissions of E-MBMS from eNodeBs A, B and C, and UEs i and j receive transmissions of E-MBMS from eNodeBs A and C respectively.
In such a scenario, the transmission powers from eNodes A and C received at the UE k may be adequate for it to be served with the E-MBMS, while UEs i and j receive adequate transmission powers from eNodeBs A and B respectively. Accordingly, it is energy inefficient to keep eNodeB B broadcasting E-MBMS with a constant transmission power.